presentation

It Works On My Machine - Reproducibility in R for Small Teams

Works on my machine - MS Teams sticker Melissa Albino Hegeman, October 19, 2023

Disclaimer

I work for NYSDEC, but the opinions I’m presenting are my own and don’t reflect agency policy.
Images were generated with Adobe FireFly

About Me

Marine biologist
Get really seasick
Work with fisheries data

How I Am Using R

Automate routine tasks
Generate individualized reports

I use R for many different things. [advance] Obviously, I want to automate all the things. Anything that I do on a schedule should me automated. I hate having to do the same thing more than a dozen times. [advance] More recently, I’ve enjoyed using R for report generation, where you need customized output for many individuals. Think a couple of thousand reports where the data is coming from several sources and you update it once a quarter. And the reports have some logic baked in so we only include the sections that are specific to the individual. This is taking mail merge up a level and has been really successful. But I’m not going to talk about that today. What I am going to talk about is what happens once you’ve proven your concept and put it into production, and now you and your team have to keep it going.

What is a Team?

10 people or less
Limited to no experience with R
No enterprise tools

Sharing the Load

What happens after you implement a big change?
Who is responsible for maintenance?
Who is responsible for new features?

Setting Up for Success

R projects
GitHub
Custom R package
{renv}

It Works on My Machine

Error in library(tidyverse) : there is no package called ‘tidyverse’
Error in plot(data) : object 'data' not found
Error in file(file_path, "r") : cannot open the connection
cannot create dir 'output', permission denied

How Do I Fix It?

R projects
GitHub
Custom R package
{renv}

R Projects

Issues

Not being used as intended

Successes

Relative file paths
First step in reproducibility
Adds portability

GitHub Repositories

Issues

Steep learning curve

Success

It’s the most efficient way to get the code on everyone’s machine
Gives team members the freedom to experiment

Custom R Package

Issues

Keeping everything in sync
Updates and maintenance

Successes

Everyone is applying the same treatment to the data no matter where they are working
Dependent on staff making sure their version was updated regularly

{renv}

Issues

Slow to boot up a project for the first time
Staff were updating the lockfile rather than adjusting their installed packages when their project was out of sync

Successes

This is still a work in progress
Wait until you are done developing before you initialize {renv}
Forced me to minimize the amount of dependencies I rely on

The last major issue we encountered was that everyone’s development environment was slightly different. {renv} is supposed to address this. Depending on when a new hire started, they might have a different version of R installed than the project was developed in. And there were dozens of different combinations of package versions floating around. We recently started using the renv package in specific projects to get everyone on the same page using the package versions used to create the project. You know, I said GitHub was the biggest learning curve, but it is actually renv. [advance] It takes a long time to get the project going after you’ve cloned a repository where renv was initialized. This might be specific to our system, but it can take an hour to start your work when using renv. That is really frustrating to newer users. [advance] Users’ libraries would frequently get out of sync with the lockfile. Most of the time, they would try to update the lockfile, which completely defeats the purpose. This package was most helpful to implement when you were done coding and only envisioned minor edits from now on. [advance] It also works better when you minimize the number of dependencies your project needs.

Solutions

Consistent and continued training for new staff
Simplify where ever you can
Avoid scope creep in your projects

Next Steps

::: notes

Everything I’ve talked about so far is from the perspective of a small group without significant IT resources to throw around. However, there is one strategy that’ve I’ve only really associated with larger programs: [advance] containers, such as docker or podman. I had been afraid to try this, it seemed really intimidating. But honestly, I’ve been experimenting with containers and it hasn’t been any more frustrating than everything that I’ve already talked about. Having this much control over the development environment is really appealing. The examples I’ve talked about to this point involved people running code already written, but everyone needs to be working toward developing new features on their own, and having a consistent environment from the start should help avoid some of the biggest roadblocks to getting started. When your trying to lead your group in a certain direction, it is really important to give them successes early on.

Thank You

Melissa Albino Hegeman

https://github.com/mhegeman/2023_rgov